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ABSTRACT 



The US military requires a reliable, high-speed, multimedia capable system to 
disseminate information that caimot be efficiently distributed over existing low data rate 
chaimels. The Global Broadcast Service (GBS) is being developed to meet this 
requirement. The cornerstones of the GBS simplex broadcast are the premises of smart 
push and user pull. An integral part of the user pull is the reach back channel. The reach 
back chaimel allows users to specify the information they need broadcast and tailor the 
information to meet their mission needs. Ultra high frequency (UHF) demand assigned 
multiple access (DAMA) satellite communications are the most widely available long 
haul communication systems available to members of the armed services and as such are 
a prime candidate to provide a reach back path for GBS. In order to fully utilize UHF 
DAMA as a reach back channel for data communications a number of interface 
requirements must be met. The problems of using UHF DAMA are discussed and 
recommendations are made for the GBS Phase Two systems so they might support the 
use of UHF DAMA as a reach back channel. This thesis shows that UHF DAMA is a 
viable reach back channel, however there are factors which could improve the efficiency. 
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EXECUTIVE SUMMARY 



The US military requires a reliable, high-speed, multimedia capable system to 
disseminate information that cannot be efficiently distributed over existing low data rate 
channels. The Global Broadcast Service (GBS) is being developed to meet this 
requirement. The GBS program is capitalizing on the huge civilian investment in direct 
broadcast satellite (DBS) technology and adapting it to meet warfighter needs. DBS 
technology offers small end-user antennas, increased mobility, and an aggregate data rate 
of up to 23 million bits per second. 

The GBS program is being developed in three phases. Phase one involves the 
lease of commercial Ku-band transponders and the use of commercial off the shelf 
(COTS) components. Although Phase One has been used primarily for testing and 
exercises, it has also supported the delivery of information to North Atlantic Treaty 
Organization (NATO) peacekeeping forces in Bosnia. Phase two is an initial military 
capability with GBS Ka-band transponders hosted on the Ultra High Frequency (UHF) 
Follow On (UFO) Satellites 8, 9, and 10. UFO 8 was launched in Spring 1998 and the 
first receive suites will be delivered in late summer 1998. Phase three, scheduled to begin 
in 2009, is the complete integration of GBS into the Defense Information Infrastructure. 
This thesis concentrates on the GBS Phase One and Phase Two systems. 

The cornerstones of the GBS program are the concepts of smart push and user 
pull. The information content of the smart push is determined at the theater level without 
real-time input from end-users at the unit level. User pull allows unit level end-users to 
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define specific information to be broadcast on demand in response to operational 
circumstances. User pull also enables end-users to request that certain smart push 
products be rebroadcast in the event that they were not received at their unit during the 
regularly scheduled smart push. Both these capabilities are enabled by the reach back 
channel. The reach back channel can be implemented with any suitable means of 
communication available to the unit level force in question. 

UHF demand assigned multiple access (DAMA) satellite communications is the 
most widely available long haul system to members of the armed services. As such, it is 
a prime candidate to provide a reach back path for GBS. In order to fully utilize UHF 
DAMA as a reach back channel for user pull communications, a number of interface 
requirements must be met. One of the problems encountered when using UHF DAMA as 
a GBS reach back channel is the substantial time delay associated with the DAMA 
protocol itself In fact, UHF DAMA may represent a worst case scenario for timing 
delays. Modem day computer communication protocols such as the ubiquitous 
Transmission Control Protocol / Internet Protocol (TCP/IP) do not tolerate long 
communications delays well. A number of systems have been developed to interface 
protocols such as TCP/IP with UHF DAMA. An example is the Automated Digital 
Network System (ADNS), a major portion of the Navy’s Joint Maritime Communications 
Strategy (JMCOMS). ADNS has developed protocols to interface computer 
communications with a large number of transmission media, including UHF DAMA. It 
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is the performance of just such an interface, the UHF DAMA channel access protocol 
(CAP), which is investigated in this thesis. 

The Naval Postgraduate School (NPS) has developed a GBS Phase One test bed 
with some unique testing capabilities. In addition, the ADNS program office has 
established a lab for testing of the ADNS CAPs at the Space and Naval Warfare Systems 
Center in San Diego (SSC-SD). The NPS test bed and the ADNS lab were connected 
using an IP tunnel through the Secure Internet Protocol Routed Network (SIPRNET). 
The tunnel established a virtual connection between the two labs and allowed testing 
using UHF DAMA SATCOM assets at SSC-SD as the reach back channel for the GBS 
receiver suite at NPS. The tests were conducted using the manual retransmit request on 
the GBS Phase One software and varying the loading on the UHF DAMA back channel. 
The manual retransmit request consists of a short (~ 200 bytes) TCP/IP connection 
between the NPS test bed and the Phase One GBS satellite uplink facility. If the 
requested files were available at the GBS uplink facility, then they were queued up and 
delivered over the Phase One GBS CONUS broadcast. If the files were not available, 
then the request failed. Parameters such as the number of users and the traffic load were 
varied on the UHF DAMA back channel until the computer communications failed. 

The results of this testing have identified some areas of concern for GBS Phase 
Two. However, it is early enough that if these concerns are addressed in a timely manner, 
then the GBS Phase Two system will support the use of UHF DAMA as a reach back 
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channel. This thesis has shown that UHF DAMA can be a viable GBS reach back 
channel if certain steps are taken to improve efficiency. 



XIV 



I. THE GLOBAL BROADCAST SERVICE 



A. HISTORY 

The Global Broadcast Service is a military adaptation of the civilian direct 
broadcast satellite (DBS) technology. DBS systems use high-power geostationary 
satellites to deliver over one hundred channels of digital audio and video directly to 
consumers. The high power satellite transponders (~53 dBW) allow the use of relatively 
small (18" - 24") consumer antennas. The fact that industry has home the majority of the 
research and development costs makes this technology attractive to the military. The 
GBS Concept of Operations (CONOPS) envisions using similar commercial technology 
to support the warfighter. The types of information and products delivered over GBS will 
include mission data updates (MDUs), air tasking orders (ATOs), Global Command and 
Control System (GCCS) and Joint Maritime Command Information System (JMCIS) 
data, meteorological and oceanographic (METOC) data and multiple video services. A 
representative list of data products identified for broadcast over GBS by United States 
Pacific Command (PACOM) is provided in Appendix A. [Ref. 1] 

B. THE GBS PROGRAM 

1. Overview 

The GBS program is being implemented in three overlapping phases. Phase one 
(FY96 - FY98+) consists of the utilization of a leased Ku-Band (14 gigahertz (GHz) 
uplink, 12 GHz downlink) commercial transponder on Hughes' SBS-6 satellite located at 
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74° West longitude. Phase two (FY-98 - FY09+) of the GBS program consists of an 
interim militairy satellite capability. The GBS Phase Two Ka-Band (30 GHz uplink, 20 
GHz downlink) transponders are hosted on the Ultra High Frequency (UHF) Follow-On 
(UFO) satellites 8, 9, and 10. UFO 8 was successfully laimched on March 16, 1998, UFO 
9 is scheduled for launch in August 1998, and UFO 10 is scheduled to be laxmched in 
March 1999. GBS Phase Two will not provide coverage of the majority of the 
continental United States. GBS phase three (FY09+) goals include worldwide coverage 
and the complete integration of GBS into the Defense Information Infrastructure. GBS 
will support the Unclassified through Top Secret Sensitive Compartmented Information 
classification levels. [Ref. 1] 

The GBS program incorporates the concepts of smart push and user pull. The 
information content of the smart push is determined at the theater level without real-time 
input from end-users at the unit level. User pull allows unit level end-users to define 
specific information to be broadcast on demand in response to operational circumstances. 
User pull also enables end-users to request that certain smart push products be 
rebroadcast in the event that they were not received, or received in a corrupted form at 
their unit during the regularly scheduled smart push broadcast. Both these capabilities are 
enabled by a reach back channel. The reach back channel(s) can be implemented with 
any suitable means of communication available that provides connectivity from the unit 
level force in question to the GBS Satellite Broadcast Manager (SBM). [Ref 1] 
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The actual method used to make a user pull request will depend on the user’s 
existing communications capabilities. The GBS Phase Two CONORS specifies four 
methods of user pull connectivity shown in Table 1 . 



Mode 


Retransmission 

Requests 


User Pull Requests 


Back Channel 
(Example) 


Receive Only 


N/A 


N/A 


N/A 


Manually Connected 


Human-in-the-Loop 


Human-in-the-Loop 


Telephone 


Partially Connected 


Human-in-the-Loop 


Human-in-the-Loop 


SIPRNET 


Fully Connected 


Automatic (Virtual 
Full Duplex) 


Human-in-the-Loop 


SIPRNET 



Table 1 GBS Reach Back Modes 



Regardless of the connectivity mode, the need for retransmission requests is 
detected automatically by the GBS receiver suite’s Receive Broadcast Manager (RBM), 
and user pull requests are, by definition, generated manually. In Receive Only (RO) 
Mode, the unit level end-user has no available means of communication except a GBS 
receiver. It is therefore not possible for the RO user to submit retransmission or user pull 
requests. The Manually Connected (MC) user may have voice or dial-up data 
communications capabilities, but no other external data network connectivity. The voice- 
only MC user will be alerted to the need to submit a retransmission request by an 
indication on the screen of the RBM or an end-user terminal connected to the RBM. The 
MC user with dial-up data communications will make use of an RBM utility that stores 
automatically generated retransmission requests in properly formatted e-mail text files. 
Depending on the internal connectivity at the unit level, the MC connected GBS user will 
get the retransmission request message file(s) to the equipment (typically another 
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computer) that has the dial-up data communications connectivity via file transfer protocol 
(FTP), internal e-mail, or simply copy it to a disc and “sneaker net” it. Both the Partially 
Connected (PC) and Fully Connected (FC) modes require that the imit level end-user 
have some form of external data network connectivity and that the GBS RBM is 
somehow wired to this connectivity (e.g., via a ship’s onboard Local Area Network - 
LAN). The PC user does not have full-time external data network connectivity while the 
FC user does. The PC user’s external network connection schedule may be tied to reach 
back satellite access periods. The PC user does not achieve “virtual full duplex” 
connectivity because a human-in-the-loop (or an automated process external to the RBM) 
is required to ensure that GBS retransmission request e-mail queue is launched when 
external data network connectivity is available (via the reach back channel). Since the FC 
user has a full-time external data network connection, the RBM-generated retransmission 
requests are launched automatically without a human-in-the-loop nor the need for any 
other external automated process. Therefore, the FC GBS user achieves “virtual full 
duplex” connectivity. To focus on the performance of UHF Demand Assigned Multiple 
Access (DAMA) Satellite Communications (SATCOM) as a GBS reach back channel, 
the research conducted for this thesis was performed with the NPS GBS receive suite in 
the Fully Connected (FC) mode. [Ref. 1 Appendix B] 

2. Phase One GBS System 

The primary purpose of the Phase One system is the refinement of the CONOPS 
and the investigation of emergent technologies that may support GBS in the future. In 
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addition, Phase One supports the Joint Broadcast Service (JBS). The IBS is a direct 
broadcast capability used in support of North Atlantic Treaty Organization operations in 
Bosnia. The JBS utilizes the Orion-1 satellite located over the Atlantic Ocean at 37.5° 
West longitude. The JBS and GBS Phase One systems share a satellite uplink facility the 
JBS Information Management Center (JIMC) which is currently located in the Pentagon. 
[Ref. 1] 

The Phase One GBS broadcast is approximately 23 megabits per second (Mbps) 
and is subdivided into channels. The broadcast uses the proprietary Hughes Corporation 
Direct Satellite System (DSS) waveform for data transmission [Ref 5]. Typical channels 
include secret Internet protocol (IP) data, imclassified IP data, secret asynchronous 
transfer mode (ATM) data, and a video broadcast. 

Figure 1 shows the components of a Phase One receive suite involved in the 
reception of an IP data channel. The broadcast is received by a 1 meter satellite dish, 
downconverted to an L-Band intermediate frequency, and sent to the integrated receiver 
decoder (IRD). The IRD is the “set top box” that allows one to select the desired 
channel. The data output of the IRD is a 15 pin parallel data port. The data bridge 
converts the parallel output of the IRD into a serial data stream for decryption by the KG- 
194A. The IP channel is typically operated at a data rate of 4 Mbps. The KG- 194 A 
decrypts the signal and provides an input to the one of the serial ports on the Cisco router. 
The Cisco router converts the serial data into the Ethernet protocol which allows a simple 
interface with the Sun workstation. For a more detailed discussion including directions 
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on how to develop a GBS Phase One receive suite from commercial components see 
Schaffler [Ref. 4]. The Phase One GBS broadcast uses the User Datagram Protocol 
(UDP) at the transport layer. UDP is a connectionless IP based protocol. Connectionless 
means that each data packet is not acknowledged. Multiple transmissions are used to 
make a best-effort at delivery, but there is no way to ensure the data has been received 
correctly on a packet-by-packet basis. 





□ 



SUN Sparc 2071 
Receive Data Manager 



Figure 1 GBS Phase One Receive Suite 



' a) GBS Reach Back via Phase One Systems 
Since GBS is a simplex link there are numerous methods used to ensure 
reception. For example, transmissions are typically repeated 3 times and may be repeated 
up to 30 times to help ensure reception. Forward error correction allows the link to 
operate at a bit error rate of less that 1x10-10, reducing corrupted files and therefore 
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reducing the need to retransmit. The only reach back communication methods available 
in the GBS Phase One software are the automatic and manual retransmit requests. The 
uplink site periodically transmits a list of all files that have been broadcast. The receive 
data manager (RDM) compares that list of files with the files that have been received. 
(The GBS Phase One RDM is referred to as the receive broadcast manager (RBM) in the 
Phase Two systems.) If there are files which have not been received there are two 
methods to request retransmission. In the automatic retransmit mode the RDM 
establishes a Transmission Control Protocol / Internet Protocol (TCP/IP) session between 
the GBS gateway computer and the RDM. The RDM then requests the files that are 
missing. In the manual retransmit mode the RDM operator selects a file or multiple files 
in the RDM X-Windows file manager and clicks on the retransmit icon. This method 
uses the same procedure as the automatic retransmit request with only the selected files 
being requested for retransmission. The full TCP/IP retransmit request for a single file 
typically consists of approximately 200 bytes in the forward direction (from the RDM to 
the GBS gateway computer) and 100 bytes in the return path. The retransmit request 
executes a common gateway interface (CGI) script at the GBS gateway. The CGI script 
queues up the file(s) for retransmission. These files are then rebroadcast via the GBS link 
provided they are still available at the gateway computer. If they are not available the 
operator is notified by the gateway computer that the retransmit request has failed before 
the TCP connection is closed. [Ref. 2] 
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In the experiment discussed in Chapter III the manual retransmit request 
will be utilized. This is the most likely configuration for a GBS user for whom UHF 
DAMA is the primary means of long haul communications. The fact that the retransmit 
request consists of a TCP/IP session allows us to extrapolate the results to other 
scenarios. For example, the request could be the acknowledgment of a high priority 
message. In addition, the PACOM CONOPS [Ref 3] describes a scenario that has 
similarities to the manual reach back request. According to the PACOM CONOPS the 
GBS satellite broadcast manager will develop and broadcast a catalog of information 
products. Users may then subscribe or request these information products via alternate 
communications systems, for example, UHF DAMA. 

3. Phase Two GBS System 

The GBS Phase Two system is composed of three major segments, the satellite 
broadcast manager (SBM), receive broadcast manager (RBM), and the space segment. I 
will concentrate on the RBM and the space segment. Currently it is plaimed that the 
RBM will use the Microsoft NT Version 4.0 operating system and Internet Explorer 4.0 
as the web browser to access the information. There are numerous configuration options 
for the Phase Two receive suite. The main differences between the receive suite 
configurations are the number and types of video and data feeds. The broadcast uses the 
European Digital Video Broadcast Standard (DVB). DVB was chosen for a number of 
reasons including its ability to support variable data rates. For a more detailed 
comparison of DVB and the Hughes’ DSS standard see Wellborn [Ref 5]. 
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When fully implemented the GBS Phase Two system will provide coverage as 
shown in Figure 2. The majority of the receive suites for the Phase Two system will 
include dual band capability. Dual band receivers allow the augmentation of the military 
Ka-band systems with commercial Ku-band capability. This will be especially important 
since there will not be any GBS coverage in the central portion of the Continental United 
States. 




- 180 . - 150 . - 120 . 

Satellite Locations: 
UFO-8: 172E 

UFO-9: 22.SW 

UFO-10: 72E 



- 90.0 - 60.0 - 30.0 0.0 30.0 

Longitude 



60.0 90.0 120 . 150 180 . 

Each UFO Satellite has two 500 NM spot beams (1,2) and one 2000 NM 
beam (3) Receive Suites must be inside one of these beams to receive the 
broadcast The spot beams can be moved throughout the satellite 
coverage area as directed by operational CINCs 



Figure 2 GBS Phase Two Coverage 
[Ref. 3] 



The Phase Two space segment consists of four transponders, two uplink antennas, 



one of which is steerable, and three steerable downlink antennas on each satellite. (Refer 



to Figure 3.) Each transponder is rated for 130 watts of transmit power and has a 3 dB 
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uplink bandwidth of 33 Megahertz. The transponder center frequencies are shown in 
Table 2. [Ref. 6] 

The fixed uplink antenna for each satellite will be pointed at a primary injection 
point (PIP). The PIPs will be located in Wahiawa, HI; Norfolk, VA; and Sigonella, Italy. 
The steerable uplink antenna may be pointed to receive information from up to three 
theater injection points (TIP). If multiple TIPs are used each would be assigned to a 
separate transponder and they must all be within a single 350 NM diameter as determined 
by the footprint of the steerable uplink antenna. [Ref. 1 ] 



Transponder Channel 


Uplink Center Frequency 
(GHz) 


Downlink Center Frequency 
(GHz) 


1 


30.095 


20.295 


2 


30.215 


20.415 


3 


30.275 


20.475 


4 


30.395 


20.595 



Table 2 GBS Transponder Center Frequencies 



[Ref 6] 

The GBS Phase Two space segment is shown in Figure 3. The downlink antennas 
offer two distinctive broadcast patterns, one 2000 nautical mile (NM) wide area coverage 
beam (at nadir) and two 500 NM spot beams (at nadir). The wide area coverage beam 
provides a 1.544 Mbps data rate while the spot beams offer a 24 Mbps data rate. The 
downlink antennas may be configured to provide up to four simultaneous 24 Mbps data 
streams distributed between the two spot beams, or three 24 Mbps data streams 
distributed between the two spot beams and one 1.544 Mbps wide area beam. [Ref 1] 
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Fixed & Steerable Uplinks Transnondans Downlink 

Broadcast Injection ** Steerable Spot Beams 




Figure 3 GBS Phase Two Space Segment 
[Ref. 3] 

a) GBS Reach back via Phase Two Systems 

The GBS Phase Two broadcast will also consist of smart push and user 
pull components. The SBM will maintain smart push interest profiles for individual 
units, battle groups, etc. These will be set up as “channels” to information source web 
sites defined by “.cdf’ files using the Microsoft FrontPage software product. (Note: 
Information providers who desire their products to be distributed via GBS will have to 
make them available at web sites on the SIPRNET or the NIPRNET.) The .cdf files then 
direct the operation of an automated search engine, i.e., a “web crawler.” The web 
crawler copies updates of desired information from the sites contained in the .cdf files to 
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a cache at the SBM. These are then smartly pushed to the unit level receive terminals 
according to the broadcast access schedule (i.e., the pointing schedules of the downlink 
beams) where they reside on the unit level users’ RBMs. The RBMs become, in effect, 
proxy web servers for the individual end-users whose workstations will be connected to 
the RBM via a LAN or other means. The content of the smart push portion of each 
broadcast is catalogued in the electronic program guide (EPG) which is also transmitted 
with the broadcast. 

In addition to the smart push products, the Phase Two GBS SBM will 
maintain a menu (in hypertext format) of products available for user pull. The SBM will 
download the current version of the user pull menu to the unit level users with each 
broadcast along with the EPG. Users will click on hypertext links to make requests from 
the available list of user pull information products. In response, the RBM generates an 
email message addressed to the SBM which will be sent via the reach back chaimel. The 
email message will be acknowledged as soon as possible by the SBM via the reach back 
channel, but the scheduling of the actual user pull data delivery via the broadcast will 
depend on CINC priorities and bandwidth availability. [Ref 9] 

The Microsoft Point-to-Point Tunneling Protocol (PPTP) is responsible for 
routing reach back email messages from the RBM to the SBM. PPTP is a built-in option 
in Microsoft NT Version 4.0, and is planned for NT Version 5.0. In addition, Windows 
95 users can download an add-on which will allow them to establish a PPTP tunnel 
between a Windows 95 client computer and an NT Server. A sample PPTP connection is 



12 



shown in Figure 4. The purpose of PPTP is to securely connect a private network to a 
remote access client. PPTP relieves the planners of some of the Internet Protocol (IP) 
addressing requirements. As can be seen in Figure 4, the actual addresses of the 
computers are not used through the Internet, only the PPTP tunnel addresses. [Refs. 9, 
21 ] 




Figure 4 PPTP Connection 
[Ref. 21] 



C. GBS REACH BACK EXPERIMENTS 

Since the first days of the GBS experiments there has been interest in how to 
deliver requests for information from users. The Joint Staff sponsors an exercise every 
year called the Joint Warrior Interoperability Demonstration (JWID). The purpose of the 
JWID exercise is to examine emerging technology and investigate how that technology 
may support the warfighter. The subject of GBS reach back has been a topic in at least 
two previous JWID exercises and is planned for a third. 
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1 . 



JWID 1996 



The Army sponsored a demonstration using the Extremely High Frequency (EHF) 
MILSTAR SATCOM system as a reach back channel for GBS. The MILSTAR System 
provided a dedicated 2400 bps point-to-point link between remote users and the Joint 
Task Force Headquarters. The demonstration was hosted onboard the USS Kearsarge, 
and at Fort Bragg, NC. The operators used INTELINK-X menu based software written 
by the Air Intelligence Agency and an All Source Analysis System - Remote Workstation 
to communicate directly with information providers via the Secure Internet Protocol 
Routed Network (SIPRNET). The requested information was wrapped and delivered via 
the SIPRNET to the GBS uplink facility. The request-to-receipt cycle time was typically 
three to five minutes, with some exceptions taking up to 15 minutes. The exceptionally 
long delivery times were attributable to the GBS broadcast queue length and poor 
weather conditions at the uplink facility which disrupted the uplink signal. [Ref. 10] 

2. JWID 1997 

The National Reconnaissance Office (NRO) Operational Support Office (OSO) 
sponsored a GBS reach back demonstration during JWID 1997. The reach back channel 
actually utilized available unused bandwidth on the SBS-6 transponder used for the GBS 
Phase One broadcast. Specifically they used a 100 watt transmitter, spread spectrum 
modulation, and a 1 .2 meter antenna. The reach back channel operated at 40 kilobits per 
second (kbps). Spread spectrum modulation was used to reduce the signal power density 
and avoid adjacent satellite interference which is problematic when using a small uplink 
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antenna. The demonstration typically received the requested data within five minutes, 
with some exceptions taking up to 30 - 40 minutes. The longer transfer times were again 
attributable to queuing delays at the uplink facility. There did not seem to be any 
correlation between file size and delivery time. The demonstration was hosted at Fort 
Gordon, GA and was a proof of concept and did not allow for other units to utilize the 
reach back channel. The technique will actually not work in GBS Phase Two because all 
in-theater uplinking capability in Phase Two is intended for the TIPs, not end users. If 
end users were to use the Phase Two uplink for reach back, they would need powerful 
transmitters at 30 GHz (see Table 2). Also, the footprint of the Phase Two steerable 
uplink spot beam would have to be pointed to include their location. [Ref. 1 1] 

3. Naval Research Laboratory Experiments 

In December 1997 the Naval Research Laboratory (NRL) began a set of 
experiments that took the concept of GBS reach back one step further. The NRL has 
demonstrated the capability to access a world wide web server via multiple reach back 
channels such as a dial up telephone line, cellular phone, dedicated 25-kHz UHF 
SATCOM, and the Planet One Data Phone. The Phase One GBS was used to deliver the 
web pages. The Planet One Data Phone is 2.4 kbps data service provided by the 
International Maritime Satellite Organization (INMARSAT). The goal of the experiment 
was to demonstrate smart “user pull” of data over the GBS system using standard 
protocols. [Ref. 13] 
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4. 



JWID 1998 



The NRO/OSO and NRL have submitted a proposal that builds upon the NRL 
experiment. The proposed JWID 1998 demonstration includes web browsing via all of 
the reach back channels in the NRL demonstration in addition to a very small aperture 
terminal (VSAT) code division multiple access (CDMA) SATCOM system. There will 
also be additional users; the proposal includes two shore-based users and one afloat user. 
[Ref. 12] 
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II. ULTRA HIGH FREQUENCY DEMAND ASSIGNED MULTIPLE ACCESS 

SATELLITE COMMUNICATIONS 

A. DAMA BACKGROUND 

The ever-increasing demand for UHF satellite communications has led to the 
saturation of the existing UHF SATCOM assets. In the 1970s Demand Assigned 
Multiple Access (DAMA) was developed as a method for multiple users to share a single 
communications channel. DAMA is basically a form of time division multiple access 
(TDMA) where the channel is partitioned into time slots which can then be assigned on a 
dynamic basis. There are several methods to access a time slot on a DAMA channel. 

In 1986 the Navy implemented DAMA in the distributed control (DC) mode. The 
DC mode involved centralized assignment of time slots within the SATCOM chaimel. 
The control site determined how the DAMA slots would be allocated and distributed a 
message with the assignments. For example, if there was a net operating on time slot 
10158 that a ship needed to participate in, then the radiomen aboard ship would enter this 
time slot number into the DAMA terminal. This would allow that ship to participate in 
that DAMA net. In the DC mode there was no dynamic reallocation of bandwidth. [Ref. 

7] 

In the automatic control (AC) mode a time slot is requested from a central 
controller via a satellite orderwire, assigned to a terminal, and released back to the 
controller once the terminal has completed using it. In the AC mode DAMA terminals 
are identified by a unique address. The ability to identify the terminals allows a DAMA 
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controller to verify that the requesting terminal is authorized to initiate or join a net, in 
addition to determining its priority. An additional capability when operating in the AC 
mode of operation is called demand assigned single access (DASA). The DASA mode 
allows a single user access to an entire channel without having to share the bandwidth. 
The request for a DASA channel is made via the user’s UHF DAMA channel. In the 
DASA mode of operation once the channel has been assigned to a user it is operated in 
the dedicated UHF SATCOM mode (MIL-STD-188-181). The DASA channel is 
allocated for a fixed time period. The user retains use of the DASA channel until he 
voluntarily gives the channel up and logs back onto his home chaimel or the timer 
expires. DASA channels cannot be preempted. [Ref. 7] 

There are currently two different UHF DAMA SATCOM waveforms, one for 
operation over 5-kilohertz (kHz) channels, and one for operation over 25-kHz channels. 
The Navy has focused on the development of the 25-kHz DAMA controllers and 
terminals (MIL-STD-188-183) for both ships and aircraft, while the Air Force has 
concentrated on the 5-kHz DAMA controllers and terminals (MlL-STD-188-182). 

B. 25-KHZ DAMA 

The 25-kHz DAMA waveform has a relatively short frame length of 
approximately 1.3866 seconds (Figure 5). The user segments are capable of being 
subdivided into over 1500 different frame format combinations, allowing users to select 
setups that would best fit their needs. A CINC communications planner typically 
specifies the frame formats. For example, the Navy often uses Frame Format 259 which 
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provides five 2400 bit per second (bps) voice or data slots in addition to twelve 75 bps 
slots and one 300 bps slot. 

When operated in the AC mode, the 2 5 -kHz waveform supports point-to-point, 
conference, and network calls. The baseband data rates supported range from 75 bps - 16 
kilobits per second (kbps). If the 16 kbps data rate is selected it occupies all of segments 
B and C, leaving only segment A for other users. The minimum time to request and 
access a time slot is three frames, one frame to request the slot, one for the controller to 
process the request, and the third for the controller’s reply. The terminal is allowed to 
start transmitting during the same frame that the reply is received. A typical time would 
then be 3 frames plus two satellite hop delays, approximately 4.6 seconds total. [Ref. 7] 




Figure 5 25-kHz DAMA Frame 
[Ref 7] 
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c. 



5-KHZ DAMA 



The 5-kHz DAMA frame is shown in Figure 6. 5-kHz DAMA was designed for 
short data messages, low speed data circuits, and limited secure voice capability for the 
Air Force’s Military Airlift Command (now Air Mobility Command). The capabilities of 
5-kHz DAMA include packetized message service, voice, and data circuit service. The 
entire 5-kHz frame is 8.96 seconds in duration, but the lengths of the time slots assigned 
for circuit use within the frame vary with the type of data, modulation, and code rate. 
The length of the time slots used for messaging can vary depending on the amount of 
unused space in each frame. The packetized message service allows up to 900 messages 
per hour with an average message size of 200 characters. The messages are typically 
generated on a laptop computer and stored until the terminal is granted access to the 
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channel. The frame length of almost 9 seconds may cause problems with voice and data 
circuits. The minimum time to set up a channel is also 3 frame cycles or almost 27 
seconds and could be longer if more, higher priority users are competing for the channel. 
Once the circuit is established the worst case delay would be at most two frames which 
makes full duplex data communications difficult, and voice communications even more 
difficult. Because of these delays, 25-kHz DAMA with its quicker cycle time or 5-kHz 
DASA are preferred for voice communications. A 5-kHz DASA circuit may be set up 
using a 25-kHz channel or a 5-kHz channel to request the circuit. The use of a 25-kHz 
channel greatly decreases the setup time. In the DASA mode of operation once the 
channel has been assigned there are no framing delays, only the satellite delay. [Ref. 7] 

D. TCP/IP OVER UHF DAMA 

DAMA is not an efficient transmission protocol for many computer 
communications. Protocols like TCP/IP have been optimized to operate over terrestrial 
links such as phone lines, fiber optic systems, etc. As mentioned earlier the frame delay 
for a 25-kHz signal is approximately 1 .4 seconds, and for a 5-kHz signal is on the order 
of 9 seconds after the connection has been established. Depending on their location in the 
frames, two users who are communicating may experience up to two frames of delay. 
Geosynchronous satellites add to this problem with a round trip delay of approximately 
0.5 seconds to transmit a signal and receive a reply. These delays can wreak havoc on 
computer protocols. 
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For example, if a system wanted to establish a TCP session with another computer 
it must complete what is known as a three-way handshake. The originating computer 
sends a TCP packet with the synchronize (SYN) flag set. If the destination computer is 
available, it will reply with an acknowledgment packet. The originating computer will 
then acknowledge this packet, thereby completing the three-way handshake. Once the 
three-way handshake is completed the data communications may begin. If the SYN is 
not acknowledged within a certain period of time the originating computer resets the 
connection. The actual amount of time each a computer will wait to establish a 
connection varies with the operating system. Once the three-way handsheike has been 
completed data can begin to be transferred. [Ref 8] 

There are two timing problems that computers face with using DAMA. The first 
is the setup of the DAMA connection. As mentioned earlier it takes up to three frames to 
setup the connection. The second is the framing delays in between communications once 
the connection has been established, the worst case scenario is approximately two frames. 
After completing the three-way handsheike the computer may begin communications. 
Each computer maintains a retransmission timer that is typically set at three seconds. If 
the destination computer does not respond within three seconds then the last packet is 
resent. If there was no reply to the second packet the TCP protocol begins an exponential 
back off where the time it waits to resend the packet doubles. It should be obvious that 
even with the relatively short 25-kHz frames there may be two frame delays and two 
satellite delays in between communications. These delays would be approximately 3.3 
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seconds, long enough to trigger the retransmission timer. In order to efficiently utilize 
DAMA for TCP/IP an additional layer of complexity must be added. 

E. IMPLEMENTATIONS OF TCP/IP OVER DAMA 

There are many different ways to approach the problem of using UHF DAMA as 
a transmission channel for TCP/IP. One such solution is the Automatic Data 
Controller/Intemet Protocol (ADC/IP) Data Controller developed by ViaSat. The 
ADC/IP has integrated a proxy server within the controller which acknowledges the 
packets as they are sent from the originating computer, buffers them, and sends them out. 
The ADC/IP uses carrier sense multiple access (CSMA) without collision detect to access 
a DASA channel. The advantage of the ADC/IP approach is that for the sending 
computer the use of DAMA as the transmission channel is transparent. The disadvantage 
is if the connection is lost there is no way to gracefully degrade the connection. This is 
because the packets have already been acknowledged and the whole TCP session is just 
dropped and must be restarted. When compared with the ADNS channel access methods 
the use of CSMA minimizes the channel access delay at the cost of reduced efficiency at 
higher traffic loads. In addition, the use of a DASA channel somewhat defeats the 
purpose of DAMA (because it can not be preempted) although the channel would be 
available for reassignment if it was released. [Ref. 14] 

The Joint Maritime Communications Strategy (JMCOMS) is a Navy program 
developed to implement the Navy’s Copernicus vision. A major portion of JMCOMS is 
the Automated Digital Network System (ADNS). The goal of ADNS is to provide 
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seamless, secure multimedia connectivity. A significant portion of the ADNS program is 
the automated network routing and switching function, which will allow the multiplexing 
of all traffic types over available Radio Frequency (RF) assets. For example, on an 
aircraft carrier (refer to Figure 7) ADNS would multiplex signals through systems such as 
Super High Frequency (SHF) SATCOM, EHF SATCOM, and UHF DAMA SATCOM. 
[Ref. 15] 

To enable the systems to function seamlessly over such diverse RF links, ADNS 
has developed channel access protocols (CAPs). One of these is the UHF DAMA CAP. 
A goal of this thesis is to examine the performance of GBS reach back over UHF DAMA 
when this ADNS CAP is employed. The typical mode of operation for ADNS and UHF 
DAMA for the Navy is the assignment of a 2.4 kbps slot on a 25-kHz DAMA channel. 
The TD-1271 B/U is the DAMA satellite modem/multiplexer used by ADNS and is 
capable of supporting four baseband channels. 

The ADNS UHF DAMA CAP functions slightly differently from the ADC/IP 
described above. The key to TCP/IP over DAMA for ADNS is the CAP Router Interface 
Unit (CRIU), see Figure 7. Consider the example mentioned earlier - the three-way 
handshake to establish a TCP session. Since the channel has a relatively high latency it is 
probable that the sending computer will have generated duplicate packets due to the 
retransmission timer. The ADNS CRIU deletes these duplicate packets generated by the 
originating computer rather than send them over an already bandwidth limited link. If the 
buffer begins to fill up, the CRIU will send an Internet Control Message Protocol source 
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quench message to the originating computer. The purpose of the source quench message 
is to stop the extra packets from cluttering up the local area network until the destination 
computer has had a chance to respond. The CRIU is responsible for monitoring the link 
and in effect developing its own retransmission timer based on channel latency to 
determine when a packet may have been lost. The channel access method used by ADNS 
is variable slot TDMA with reservation. It has guaranteed minimum access, allowing 
users to reserve a time slot and expand their access by request. The typical maximum 
number of simultaneous TCP/IP users that the ADNS UHF DAMA CAP is four. [Ref. 
16] 
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Figure 8 shows a notional ADNS UHF CAP configuration with two users, each 
with one frame of data. The DAMA channel that is assigned to ADNS is 2.4 kbps; 
therefore the number of bits available each frame is 24006//5'/ sec*1.3866sec = 33327bits 
or approximately 416 bytes. Within the UHF DAMA CAP each user can be assigned up 
to 8 time slots, there can be up to four users, and since each user is half-duplex there must 
be one blank fimne in between users so other users can be sure that the previous user is 
finished. In addition, there is a network join frame which allows a node to request entry 
into an existing network and the associated blank DAMA frame at the end of the ADNS 
frame. The total cycle time with four users, each with the maximum amount of data is 
((4users * 9 frames) + (\add + \blank)) * 1.3866sec/ frame = 52.69 sec . This was designed 
to limit the total cycle time to under one minute to support TCP applications such as the 
file transfer protocol (FTP). When compared with the ADC/IP, the ADNS channel 
access method is less efficient at lower loads (e.g. one user with one data frame would 
result in at least a 75% overhead), but more efficient as the net becomes congested. 
[Refs. 15, 16] 
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F. TCP/IP OVER DAMA SUMMARY 

There are quite a few problems inherent with attempting a TCP/IP data connection 
using UHF DAMA. TCP/IP has not been optimized to operate over high latency links. 
The UHF DAMA 5-kHz and 25-kHz frame structures incur relatively high latencies. 
Because of DAMA’s framing delays, it cannot support a direct connection between two 
computers without a third party system which governs data access to the channel or time 
slot. It is the performance of just such a third party system, the ADNS UHF DAMA 
CAP, that will be investigated in the following chapters. 
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III. EXPERIMENT SETUP 



A. BACKGROUND 

The Naval Postgraduate School (NPS) established a GBS receive suite in the 
Spring of 1997. [Refs. 4, 18] The lab is used primarily for thesis research and GBS 
experimentation. [Refs. 5, 17] The lab configuration is shown in Figure 9. The GBS 
Receive Data Manager (RDM) was initially installed in a receive-only configuration. 
Therefore the initial step in preparation for this experiment was to configure the RDM to 





KU Band Satellites 


SBS^ 


74 deg W 


GBS 


DBS 1.2.3 


101 deg W 


DirecTV 


Galaxy4 


99degW 


DirecPC 


EchoStar 1,2 


119degW 


Dishnetworfc 



Naval Postgraduate School 
CONUS GBS Receiver Suite 
Testbed 




FreberdGOOO 
Brt Error Rate Tester 



Spectrum Analyzer 
HP 8563 



150 MHZ Pentiun with LatMew 
Signal Analysis Software 



Figure 9 NPS GBS Test Bed 



29 




allow reach back communications with the GBS gateway at the JIMC in the Pentagon. 
The NPS GBS Test Bed already had Secure Internet Protocol Routed Network 
(SIPRNET) connectivity when this work started. A SIPRNET connection was added to 
the RDM (as shown in Figure 9) and it was confirmed that files could be requested from 
the GBS gateway directly through the SIPRNET with the GBS Phase One software. 
Once this was completed, the various segments of the UHF DAMA SIPRNET connection 
were added in one at a time. Troubleshooting was performed on each segment as it was 
added. 



B. TEST CONFIGURATION 

The GBS reach back test configuration is show in Figure 10. The ADNS program 
office has established a lab located in building 660 at the Space and Naval Warfare 
Systems Command (SPAWAR) Systems Center - Sam Diego (SSC-SD). The lab has 
been designed mainly for testing and validation of the CAPs. To avoid the added 
expense and labor of duplicating these facilities at NPS, the SSC-SD ADNS lab was used 
to provide access to UHF DAMA SATCOM. The ADNS lab also has the capability to 
access SHF and EHF satellites via the appropriate CAPs. The normal configuration for a 
UHF DAMA SATCOM data connection is from the ship to a regional Naval Computer 
and Telecommunications Master Station (NCTAMS) where the information can be sent 
forward via a terrestrial SIPRNET connection. This is the type of configuration used for 
our test, with the ADNS lab simulating a NCTAMS. This was accomplished by setting 
up both ends of the UHF DAMA SATCOM link (one which would typically be aboard a 
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ship, and the other at the NCTAMS) and routing data to the SIPRNET as shown in Figure 

11 . 




One of the main challenges faced in setting up this test concerned the routing of 
the reach back requests through the SIPRNET. Specifically, it was necessary to force the 
reach back request to go through the UHF DAMA CAP located at the ADNS lab and 
ensure the retransmit request acknowledgments from the gateway computer (at the JIMC) 
came back along the same path (i.e., through the ADNS lab and the UHF DAMA 
SATCOM circuit) rather than some other SIPRNET path to the NPS RDM. If no special 
action were taken, when the GBS operator at NPS made a reach back request, the IP 
packet would show the NPS IP address as the source and the GBS gateway IP address as 
the destination. Assuming we could statically route the request through the UHF DAMA 
channel (which would be a challenge in itself with all of the intermediate routers in the 
path), the problem remains as how to ensure the reply from the GBS gateway does not 
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come directly back through the SIPRNET to NPS and skip the UHF DAMA channel 
entirely. 

1. Tunnel Connection 

The solution involved setting up a KAQ9 Network Operating System (NOS) 
tunnel between two Cisco routers, one located at NPS and one located at SSC. (See 
Figure 11.) In addition to the tunnel, an IP address from the ADNS lab subnet was 
assigned to the GBS RDM. As far as the computers were concerned, the use of an ADNS 
IP address allowed the NPS RDM in Monterey to “look like” it was physically located at 
SSC in San Diego. 

The KAQ9 NOS tunnel is a selectable mode of operation on the Cisco routers 
which allows disco ntinguous sections of a Local Area Network (LAN) to be connected. 
The protocol is based on the KAQ9 NOS packet radio protocol for TCP/IP. Each end of 
the tunnel has a specific IP address as shown in Figiue 11. The tunnel encapsulates the 
IP datagram with a destination address of the other end of the tunnel. Once the datagram 
reaches the other end of the tunnel it is unwrapped and sent out in the normal manner. To 
the computers connected at each end of the tunnel it looks as if the other section of the 
LAN is only one router hop away, while in fact it may be many hops away. (In our case 
there were approximately six hops from NPS to the SSC ADNS lab without the tunnel.) 
The tunnel interface display is shown in Figure 12. The important fields are described 
below the figure. 
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Referring to Figure 1 1, the signal flow is as follows: 

• The GBS RDM operator makes a request 

• The packet is sent through the tunnel to the ADNS Cisco router #1 

• The ADNS Cisco router #1 static routes anything destined to the GBS 
Gateway via UHF DAMA 
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• The GBS Gateway acknowledges the packet and replies to the GBS RDM 
(whose address is a part of the SSC subnet) 

• The reply is static routed back through the UHF DAMA channel by the ADNS 
Cisco Router #2 

• After the reply is received it is sent by the ADNS Cisco router #1 via the NOS 
tunnel to the NFS RDM 



1 . nps#show interface tunnel 0 

2. TunnelO is up, line protocol is up 

3. Hardware is Routing Tunnel 

4. Internet address is 140.199.199.97, subnet mask is 255.255.255.248 

5. MTU 1500 bytes, BW 9 Kbit, DLY 500000 usee, rely 255/255, load 1/255 

6. Encapsulation TUNNEL, loopback not set, keepalive set (10 sec) 

7. Tunnel source 207.85.236.1, destination 192.84.124.36 

8. Tunnel protocol/transport KA9Q-NOS/IP, key disabled, sequencing disabled 

9. Checksumming of packets disabled 

10. Last input 2w6d, output 0:00:04, output hang never 

1 1 . Last clearing of "show interface" counters 4w5d 

12. Output queue 0/0, 0 drops; input queue 0/75, 0 drops 

13. 5 minute input rate 0 bits/sec, 0 packets/sec 

14. 5 minute output rate 0 bits/sec, 0 packets/sec 

15. 82700 packets input, 5287830 bytes, 0 no buffer 

16. Received 0 broadcasts, 0 runts, 0 giants 

17. 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort 

18. 380322 packets output, 26048407 bytes, 0 underruns 

1 9. output errors, 0 collisions, 0 interface resets, 0 restarts 

Figure 12 Tunnel Interface 

Referring to Figure 12, the tunnel statistics of particular interest are: 

• Line 1 is the command on the Cisco to view the tunnel statistics. 

• Line 4 shows the IP address of the NPS end of the tuimel (this is the address 
that the static route from the RDM is set to). 
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• Line 7 shows the IP addresses of the NPS and SSC-SD routers at each end of 



the tunnel. 

• Line 8 shows the tunneling protocol. 

• Lines 1 5 and 1 8 show the number of packets input to the tunnel and number of 
packets output from the tuimel respectively. Clearing the counters and using 
the ping utility allowed us to determine if the packets were being routed 
properly. Ping would send a fixed number of packets to a destination IP 
address and then we could look at the counter and determine if they had 
actually been routed through the tunnel. 

C. DATA COLLECTION 

The purpose of the data collection was to evaluate the effectiveness of the ADNS 
CAP and UHF DAMA SATCOM as a reach back channel for the GBS Phase One 
system, and then interpret the data as they apply to GBS Phase Two. As discussed in 
Chapter I, this experiment would be impossible without a CAP or some other protocol 
which handles the timing and interface requirements to transmit TCP/IP over UHF 
DAMA. The majority of the data collection involves the use of the UNIX command 
snoop which allows us to monitor and time tag all activity taking place on a specific 
network device. A sample session and labels for the columns are shown in Table 3. To 
save space, some of the additional information normally found in the snoop output has 
been deleted. The colunrn headings are explained below the table. 
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The NFS RDM has two network devices; leO which is connected directly to the 
GBS Cisco router, and lei which is connected to the SIPRNET (as shown in Figure 9). 
Snoop must be run while logged in with root privileges. The command line entry is 
Vosnoop -d lei -tr hostname. The -d lei option allows us to filter packets only on the lei 
network device. The -tr option time stamps all packets received relative to the first 
packet with an accuracy of +/- 4 microseconds. The hostname option allows some 
additional filtering so that only packets addressed to or from the specified hostname will 
be displayed. [Ref 19] 
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Table 3 Sample Snoop Line 

• Time - relative time since last event 

• Orig - originating computer (daffey is an alias for the RDM) 

• Dest - destination computer 

• Type - type of connection e.g. FTP, TCP... 

• Dest Port - Destination port 

• Source port 

• Special - in this case SYN is used when establishing a TCP session, usually 
blank 
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• Sequence Number of packet 

• Data - Number of bytes of data contained in packet 

Snoop was the primary tool used to collect data during all of the reach back trials. 
The data collection and results are described in the following chapter. 

D. ADNS CAP LOADING 

The test was conducted with the RDM directly connected to the SIPRNET and 
under varying loads on the GBS reach back UHF DAMA SATCOM channel. The loads 
on the back channel were: 

• Two users (each is 14 of a full duplex link) 

• Four users no load 

• Four users 25% load 

• Four users 50% load 

The loads were defined as follows. A four user frame with a 25% load is shown 
in Figure 13. Each user is allowed up to eight frames of data, therefore a 25% load would 
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utilize two of the eight frames. The load determines the minimum response time of the 
link. If there is only one user with one data frame (not a very efficient use of the link) 
ADNS would use four DAMA frames and the total ADNS frame length could be as short 
as 5.5 seconds. As mentioned in Chapter II, when fully loaded (four users each with 8 
frames of data) the link cycle time is 52.69 seconds. 

E. EXPERIMENT SETUP SUMMARY 

With all of the equipment properly configured, the routing problems solved, and 
the data collection plan in place, all that remained was to run the tests. The tests were 
conducted 6-17 April 1998 utilizing the Phase One GBS secret IP channel. The specific 
results are discussed in the next chapter. The tunnel remains active although the default 
route has been removed to facilitate future testing. 
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IV. TEST RESULTS 



A. DISCUSSION 

Tests were conducted varying the UHF DAMA channel loading and number of 
users parameters discussed in the previous chapter. Each configuration was tested until 
there were ten successful reach back sessions or until it became obvious that the link was 
not going to work. One of the key points that became obvious early on as we began to 
add additional users and traffic was that the TCP session would be closed by the RDM if 
it had not received an acknowledgment to its SYN packet (the beginning of the three-way 
handshake) from the GBS gateway within 30 seconds. An example of a failed session is 
shown in Figure 14. This particular example is from a test with four users and a 25% 
load. The only differences between Figure 14 and the explanation of the snoop display in 
the previous chapter are the RST in line 4 which indicates the connection has been closed 
out since there was no response within 30 seconds and the ACK field in line 5 (which is 
the acknowledgment of a packet from the destination computer). Once a session had 
been established (the three-way handshake completed), it was satisfactory if the 
subsequent acknowledgments took longer than 30 seconds, and several did. Timely 
acknowledgment of the initial SYN packet was the critical factor. 

1 0.00000 daffey -> GBS_GATEWAY TCP D=80 S=32966 Syn Seq=3 178448483 Len=0 

2 4.73776 daffey -> GBS_GATEWAY TCP D=80 S=32966 Syn Seq=3 178448483 Len=0 

3 14.20794 daffey -> GBS_GATEWAY TCP D=80 S=32966 Syn Seq=3 1 78448483 Len=0 

4 29.99909 daffey -> GBS_GATEWAY TCP D=80 S=32966 Rst Seq=3 1 78448484 Len=0 

5 3 1 .34264 GBS_GATEWAY -> daffey TCP D=32966 S=80 Syn Ack=3 178448484 Seq= 15481 24364 len=0 

6 3 1 .34279 daffey -> GBS_GATEWAY TCP D=80 S=32966 Rst Seq=3 1 78448484 Len=0 

Figure 14 Failed Reach back Session 
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The GBS RDM operating system - Sun Solaris 2.5.1 has a utility called ‘ndd’ 
which allows manipulation of the TCP/IP driver configuration parameters. These 
configurable parameters can be viewed by typing the command Vmdd /dev/tcp \?. The 
names of the parameters are somewhat self explanatory, e.g. 
TCP_CONN_ABORT_THRESHOLD. I was able to vary how long the RDM waits to 
retransmit a packet. Unfortunately, I was unable to have any impact on the problem of 
the driver resetting the connection if it had not received the S YN ACK within 30 seconds. 

B. OBSERVATIONS 

During the initial test setup we were unable to establish the tunnel connection 
between NPS and SSC. The difficulty turned out to be the SSC firewall which was 
blocking our connection. After discussing our test with the appropriate security 
personnel, we were able to get access through the firewall and complete the tunnel. 

When we first switched from a direct SIPRNET connection to using the UHF 
DAMA back channel, there were a large number of Internet Control Message Protocol 
(ICMP) messages being sent over the link. The GBS RDM would send an ICMP 
message every few seconds until it got a response; this occurred approximately every 
thirty seconds. The RDM would send about ten packets until the first response was 
received. After some investigation it was determined that the xferit script (running on the 
RDM) was the culprit. Xferit is the process that transfers wrapped information product 
files to the GBS gateway for broadcast. If a RDM was setup to allow users to wrap files, 
the process would check the link to the GBS gateway every 30 seconds and then check 
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the outgoing wrapped directory to see if there were any files to upload. A quick fix from 
Welkin & Associates changed the script so it checked the outgoing wrapped directory 
first, and then checked to see if the GBS gateway was reachable. Therefore the ICMP 
messages would only be sent when there were files to upload. This eliminated the extra 
traffic on our high latency, bandwidth restricted reach back channel. 

When directly connected to the SIPRNET (i.e., not via the UHF satellite) the 
reach back session took approximately 1.35 seconds to complete. The requested file 
consistently showed up on the broadcast 1 to 2 minutes after the request. When using 
UHF DAMA as the reach back channel, the requested file would often arrive before the 
user pull TCP/IP session had actually completed. This was due to the fact the TCP/IP 
session took so long to complete (see Table 4). The GBS gateway would have all of the 
information it needed to queue up the file before all of the handshaking was completed to 
close out the TCP/IP reach back session. As discussed in Chapter I, some of the previous 
reach back experiments have experienced wide ranges in file delivery time. This has 
been attributed to the queuing at the JIMC GBS Gateway. This effect was not observed 
during the experiments conducted for this thesis. The amount of traffic at the uplink 
facility did not seem to have an appreciable impact on file delivery times. The testing 
was conducted over a two-week period and traffic on the Phase One GBS IP data chaimel 
ranged from none up to 2 Mbps (the channel allocation is 4 Mbps). Different files were 
requested each time, and their sizes ranged from approximately 100 kilobytes up to 5 
megabytes. 
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C. SUCCESSFUL REACH BACK SESSION 

An example of a suceessful reach back session is shown in Figure 15. The line 
numbers have been added to facilitate discussion of what is actually occurring in the 
session. 

• Lines 1-3 are the initial SYN packet and the retransmission due to time-outs. 
Three SYNs were sent before a response was received from the GBS Gateway. 

• Line 4 is the acknowledgment from the GBS gateway, (this one made it with 
less than 0.2 seconds to spare before the session would have timed out) 

• Line 5 is the ACK from the GBS RDM that completes the three-way 
handshake to establish a TCP/IP connection. 

• Lines 6-1 1 are the initial transmission and time-out retransmissions of the first 
data packet. Notice the packet contains 164 bytes of data, this was consistent 
for all of the reach back sessions. The time between successive transmissions 
is approximately 0.5, 1, 2, 4, and 8 seconds. This is the TCP/IP exponential 
back-off algorithm where if an ACK is not received the time to retransmit is 
doubled up to a maximum 64 seconds typically. [Ref. 8] 

• Line 12 is the acknowledgment of the first data packet. It can be seen the 
acknowledgment takes over 30 seconds yet the connection is not reset. This is 
because once the TCP connection is established, a (different) timer is used that 
takes into account the round trip time of a connection. [Ref. 8] 
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0.00000 daffey -> GBS_GATEWAY TCP D=80 S=33291 Syn Seq=l 503463643 Len=0 
4.73658 daffey -> GBS_GATEWAY TCP D=80 S=33291 Syn Seq=l 503463643 Len=0 
14.20666 daffey -> GBS_GATEWAY TCP D=80 S=33291 Syn Seq=l 503463643 Len=0 
29.83600 GBS_GATEWAY -> daffey TCP 0=33291 S=80 Syn Ack=l 503463644 Seq=154141740 Len=0 
29.83619 daffey -> GBS_GATEWAY TCP 0=80 S=33291 Ack=154141741 Seq= 1503463644 Len=0 

29.88020 daffey -> GBS_GATEWAY TCP 0=80 S=33291 
30.35641 daffey -> GBS_GATEWAY TCP 0=80 S=33291 
31.32370 daffey -> GBS_GATEWAY TCP 0=80 S=33291 
33.23655 daffey -> GBS_GATEWAY TCP 0=80 S=33291 
37.07651 daffey -> GBS_GATEWAY TCP 0=80 S=33291 
44.75648 daffey -> GBS_GATEWAY TCP 0=80 S=33291 
59.04906 GBS_GATEWAY-> daffey TCP 0=33291 S=80 
59.04924 daffey -> GBS_GATEWAY TCP 0=80 S=33291 
59.52643 daffey -> GBS_GATEWAY TCP 0=80 S=33291 
60.48656 daffey -> GBS_GATEWAY TCP 0=80 S=33291 
62.40657 daffey -> GBS_GATEWAY TCP 0=80 S=33291 
66.24642 daffey -> GBS_GATEWAY TCP 0=80 S=33291 
73.92655 daffey -> GBS_GATEWAY TCP 0=80 S=33291 
85.37959 GBS_GATEWAY -> daffey TCP 0=33291 S=80 
85.39577 GBS_GATEWAY -> daffey TCP 0=33291 S=80 
85.40890 GBS_GATEWAY -> daffey TCP 0=33291 S=80 
85.40902 daffey -> GBS_GATEWAY TCP 0=80 S=33291 
102.49492 GBS_GATEWAY-> daffey TCP 0=33291 S=80 
102.50556 GBS_GATEWAY-> daffey TCP 0=33291 S=80 
102.50567 daffey -> GBS_GATEWAY TCP 0=80 S=33291 
102.51222 GBS_GATEWAY -> daffey TCP 0=33291 S=80 
102.53765 GBS_GATEWAY -> daffey TCP 0=33291 S=80 
102.53777 daffey -> GBS_GATEWAY TCP 0=80 S=33291 
102.56203 GBS_GATEWAY -> daffey TCP 0=33291 S=80Fin Ack=l 503463841 Seq=154141933 Len=0 
102.56215 daffey -> GBS_GATEWAY TCP 0=80 S=33291 Ack=l 54141 934 Seq=l 503463841 Len=0 
102.56273 daffey ->GBS_GATEWAY TCP 0=80 S=33291 Fin Ack=154141934 Seq=1503463841 Len=0 
102.62790 GBS_GATEWAY-> daffey TCP 0=33291 S=80Fin Ack=1503463841 Seq=154141741 Len=192 
102.62804 daffey -> GBS_GATEWAY TCP 0=80 S=33291 Ack=154141934 Seq=l 503463842 Len=0 

103.03647 daffey -> GBS_GATEWAY TCP 0=80 S=33291 Fin Aclc=154141934 Seq=1503463841 Len=0 
103.99670 daffey -> GBS_GATEWAY TCP 0=80 S=33291 Fin Ack=154141934 Seq=1503463841 Len=0 
105.91640 daffey -> GBS_GATEWAY TCP 0=80 S=33291 Fin Ack=154141934 Seq=1503463841 Len=0 
109.75649 daffey -> GBS_GATEWAY TCP 0=80 S=33291 Fin Ack=154141934 Seq=1503463841 Len=0 
1 17.43644 daffey -> GBS_GATEWAY TCP 0=80 S=33291 Fin Ack=154141934 Seq=l 503463841 Len=0 
118.43854 GBS_GATEWAY -> daffey TCP 0=33291 S=80 Fin Ack=l 503463841 Seq=154141809 Len=124 
1 18.43866 daffey -> GBS_GATEWAY TCP 0=80 S=33291 Ack=154141934 Seq=l 503463842 Len=0 

132.79644 daffey -> GBS_GATEWAY TCP 0=80 S=33291 Fin Ack=154141934 Seq=1503463841 Len=0 
134.75847 GBS_GATEWAY -> daffey TCP 0=33291 S=80 Fin Ack=1503463841 Seq=154141854 Un=79 
134.75862 daffey -> GBS_GATEWAY TCP 0=80 S=33291 Ack=154141934 Seq=l 503463842 Len=0 

134.76293 GBS_GATEWAY -> daffey TCP 0=33291 S=80 Ack=l 503463842 Seq=l54141934 Len=0 



Ack=154141741 Seq=l 503463644 Len=164 
Ack=154141741 Seq= 1503463644 Len=164 
Ack=154141741 Seq=l 503463644 Len=164 
Ack=154141741 Seq= 1503463644 Len=164 
Ack=154141741 Seq= 1503463644 Len=164 
Ack=154141741 Seq= 1503463644 Len=164 
Ack=1503463808 Seq=154141741 Len=0 
Ack=154141741 Seq=l 503463808 Len=33 
Ack=154141741 Seq=l 503463808 Len=33 
Ack=154141741 Seq=l 503463808 Len=33 
Ack=154141741 Seq=l 503463808 Len=33 
Ack=154141741 Seq=l 503463808 Len=33 
Ack=154141741 Seq=l 503463808 Len=33 
Ack=1503463841 Seq=154141741 Len=0 
Ack=1503463841 Seq=154141741 Len=31 
Ack=1503463841 Seq=154141772 Len=37 
Ack=154141809Seq=1503463841 Len=0 
Ack=1503463841 Seq=154141809 Len=20 
Ack=l 503463841 Seq=154141829 Len=25 
Ack=154141854 Seq=1503463841 Len=0 
Ack=1503463841 Seq=154141854 Len=2 
Ack=1503463841 Seq=154141856 Len=77 
Ack=154141933 Seq=1503463841 Len=0 



Figure 15 Successful Reach back Session 



• A similar pattern continues until the GBS Gateway begins to send data back to 
the GBS RDM. (Note: These data are not the requested file, but rather status 
information from the GBS gateway, e.g., file availability) 

• Once all of the data has finished being transmitted from the GBS gateway it 
sends a FIN packet on line 29. 
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•The GBS RDM acknowledges the FIN (line 30) and sends its own FIN on line 
31. 

•The session is closed out once the GBS RDM receives an ACK for its FIN 
packet on line 44. 

•The additional FIN packets being exchanged are due to the fact that they were 
not filtered in the ADNS queue. 

D. TOTAL TIME TO COMPLETE REACH BACK SESSION 

Total time, defined as the time from the first SYN sent from the RDM until the 
final ACK was received closing out the TCP session, was chosen since it represents the 
entire time that the UHF DAMA channel was occupied and not available to other users. 
The total time for the session to complete turned out to be directly related to the amount 
of traffic and the number of users. This makes sense since more users and more data 
expand the total time for an ADNS frame. The summary results are shown in Table 4. 
The reason none of the 50% load attempts were successful is explained in Section E. 





Direct 

Connect 


Two Users 


Four Users 
No Load 


Four Users 
25% Load 


Four Users 
50% Load 


Attempts / 
Successful 


10/10 


10/10 


10/10 


10/13 


0/14 


Percent 

Successful 


100% 


100% 


100% 


76.9% 


0% 


Mean Time 


1.356 


78.76 


79.31 


112.01 


NA 


Std Dev 


0.079 


2.95 


3.21 


5.58 


NA 



Table 4 Total Time to Complete Reach Back 
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There is not a large difference between the two user configuration and the four 
user no load configuration. This is because the version of ADNS software that was used 
removes members from the net if they have not sent data recently. Therefore the two 
users who were not active participants in the four user net were removed after a period of 
inactivity. If there was no activity within ten cycles the user was dropped. 

E. TIME TO FIRST ACK 

The critical factor influencing the number of successful attempts in Table 4 was 
the time elapsed before acknowledgment of the SYN sent by the RDM. The actual 
response time for the SYN ACK is shown in Table 5. None of the four user 50% load 
tests were successful since the average response time did not come close to the required 
30 seconds. The four user 25% load result really depended on where the ADNS frame 
was at in its cycle when the request hit it. For example, if the GBS user was ADNS user 
one and if user one’s time slot had just passed when the request hit the CAP queue, it 
would have to wait one whole cycle until it went out. The ACK would then take up to 
almost two cycles to get back. 





Direct 

Connect 


One User 


Four User No 
Load 


Four User 25% 
Load 


Four User 
50% Load 


Mean Time 


.260 


16.62 


17.24 


26.77 


41.32 


Std Dev 


.023 


2.51 


0.92 


5.07 


4.87 



Table 5 Average Time to First ACK 
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F. TEST RESULTS SUMMARY 

The results of the testing identified limitations of the ADNS CAP interface for the 
use of UHF DAMA SATCOM as a reach back channel for GBS. If the CAP has a round 
trip cycle time of greater than thirty seconds, then GBS reach back with this set of 
TCP/IP parameters will not work. The testing reported here actually has application to 
TCP/IP data connections in general. As shown here, the choice of computer operating 
system has a direct impact because the TCP/IP parameters vary with operating system. 
The implications of this testing for the GBS Phase Two systems, and recommendations 
for further research are discussed in the following chapter. 
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V. 



CONCLUSION 



A. APPLICATION TO CBS PHASE TWO 

This experiment was performed using the GBS Phase One Testbed and the GBS 
Phase One Receive Suite. The GBS Phase One receive suite is based on the UNIX 
operating system, while the GBS Phase Two systems will be based on Microsoft 
Windows NT. What is the relevance of this experiment to the GBS Phase Two system? 
This chapter will address that question, discuss the application of this testing to 5-kHz 
UHF DAMA SATCOM, and recommend future areas for thesis research. 

B. GBS PHASE TWO SYSTEMS 

If one of the goals of the GBS program is to integrate their system into existing 
communications architectures in a seamless manner, then design configurations must take 
into account legacy military system specifications. The goal of GBS to use commercial 
off the shelf (COTS) solutions is admirable, but there are existing military systems which 
may hamper the use of COTS solutions. 

UHF DAMA SATCOM was developed to add flexibility to the existing UHF 
SATCOM infrastructure. The decision to adopt DAMA as the “protocol of the future” 
for UHF SATCOM was made before the explosion of TCP/IP based Internet digital 
communications such as the World Wide Web, Email, Telnet and File Transfer Protocol 
(FTP). With hindsight, the UHF SATCOM DAMA protocols might have been developed 
differently to enhance support of data communications. The result of a long acquisition 
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process and slow fielding of UHF DAMA has resulted in commercial technology 
eclipsing military capabilities again. COTS - based programs such as GBS must ensure 
that the drive to adopt COTS solutions takes into account legacy military system 
requirements. 

The GBS Phase Two RBM must have the capability and flexibility to interface 
with systems ranging from 

• Hardwired SIPRNET Connection - variable bandwidth, low latency 

• Dial Up Coimection - (STU-IIl, 1200-9600 bps) 

• SHF SATCOM - high bandwidth, relatively low latency 

• EHF SATCOM - limited bandwidth, relatively low latency 

• UHF DAMA SATCOM - limited bandwidth, high latency 

• And other systems such as the Army’s Mobile Subscriber Equipment... 

What will provide this flexible capability? At a minimum, the systems should 
have the capability to adjust the TCP/IP coimection parameters, or at least have different 
“standard” configurations which allow the system to take into account variable reach 
back communications methods. This capability would eliminate the problems identified 
in Chapter IV. It will not solve the high latency problems because they are an artifact of 
the channel being utilized, but at least the comiection would work. 

C. 25 KHZ UHF DAMA VERSUS 5 KHZ UHF DAMA 

The equipment used for this test limited us to the use of 25-kHz UHF DAMA 
SATCOM. The TD-1271 multiplexer and the AN/WSC-3 UHF transmitter are designed 
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to work only with 25-kHz DAMA. This test would be practically impossible to repeat 
using a protocol like the ADNS CAP and 5-kHz DAMA because of its longer frame 
length (8.96 seconds versus 1.3866 seconds). In addition, the ADNS approach of time 
sharing a small portion of the channel would only increase the framing delays by 
overlaying its own set of delays. This is where an interface such as the ADC/IP discussed 
previously might help. As mentioned, the ADC/IP is operated in the DASA mode and 
access to the channel is governed by the CSMA protocol. This is a logical approach for 
this type of channel and it minimizes the channel access times (which is important with 
the large framing delays). 

Nonetheless, there are two drawbacks to the ADC/IP approach. First, the 
efficiency of a CSMA system is dependent on the size of the data frames and the total 
propagation time of the link. [Ref. 20, Chapter 13] For UHF DAMA SATCOM the 
protocol framing delays and satellite round trip delay combine to increase the propagation 
time, therefore decreasing the maximum utilization of the link. The second problem is 
implementation-related and that is the paucity of UHF DAMA channels to provide 
dedicated data service. Recall that DASA channels cannot be preempted. 

In my opinion, the best solution is to try to piggyback any GBS reach back onto 
existing communications channels. The probability of having a UHF DAMA SATCOM 
channel dedicated for such a low duty cycle connection is extremely small. This is the 
mode of operation I would expect for a system using ADNS and in particular the ADNS 
UHF DAMA CAP. 
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D. RECOMMENDATIONS FOR FUTURE RESEARCH 



As discussed in Chapter II, the GBS Phase Two receive suite RBM will use email 
and PPTP as the initial reach back communications method. The NPS GBS Test Bed has 
a Windows NT machine on the same local area network (LAN) as the GBS RDM. The 
SSC-SD ADNS lab has an NT server on the same LAN as the ADNS CAPs. We are in 
the process of establishing a PPTP tunnel between the two computers and will perform a 
similar test, only with the routing being handled by the PPTP connection rather that the 
NOS tunnel. Of particular interest will be the additional overhead added by PPTP. The 
test setup is shown in Figure 16. The plan is to present the results of the PPTP testing in 
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a paper at MILCOM 1998. 

Additionally, experiments involving other protocol/systems which interface 
computer communications with UHF DAMA would be useful. For example, the ADC/IP 
and AN/PSC-5 UHF DAMA System. 

E. SUMMARY 

This thesis has demonstrated that GBS reach back via UHF DAMA SATCOM is 
indeed a viable option. The actual implementation of such a capability relies on factors 
such as the GBS Phase Two receive suites, access to a UHF DAMA channel, and for non- 
ADNS users, a protocol to access the channel that allows it to support TCP/IP 
communications. 
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APPENDIX A GBS PRODUCTS 
[Ref. 1] 





Information Product 


Data 




Class 


Pt. Of Origin 


SBM 


End User 
HW/SW Rqmts 






Data 


AA/ 






Source 




1 


MAPPING, CHARTING AND 
GEODESY ((GGIS)) 


X 




S 


NIMA -St. Louis 


SIPRNET 


Browser Applications 


2 


METEOROLOGICAL AND 
OCEANOGRAPHIC (METOC) 


X 




s 


NPMOC 


SIPRNET 


Browser, MPEG viewer 


3 


ARMY NOTICES OF 
AMMUNITION 
RECLASSIFICATION (NARS) 


X 




u 


HQ,JOC 


AUTODIN 


AMHS 


4 


MISSILE NOTICE OF 
AMMUNITION 
RECLASSIFICATION (NARS) 


X 




u 


HQ, MICOM 


AUTODIN 


AMHS 


5 


OVERHEAD FIRE 
SUPPLEMENTAL NOTICES 


X 




u 


HQ, JOC 


AUTODIN 


AMHS 


6 


TPFDL 


X 




s 


CINCPAC J3/4/5 


GCCS 


GCCS RDA 


7 


COMMON TACTICAL PICTURE 


X 




s 


J3 (GCCS/JMCIS) 


GCCS 


GCCS 3.0 


8 


TOMAHAWK LND CRUISE 
MISSILE ATK MSN SUPPORT 


X 




TS 


CMSA (CRUISE 
MISSILE SUPPORT, 
USPACOM AND 
USACOM) 


CP SMITH 
B/20 


7AF=MDS , Ships=Fire 
Control Sys 


9 


ATO 


X 




s 


7 AF 


OSAN 


CTAPS 


10 


SOFTWARE 

UPDATES/PATCHES 


X 




TSC 


MULTIPLE 

SOURCES 


JICPAC et al 


? 


II 


MEDICAL INTELLIGENCE 


X 


X 


u 


AFMIC, WHO, JTF 


ArMedSurvA 

cty 


WALTER REED 


12 


GTN (ITV, JTAV/JTAD) 


X 


X 


u,s 


USTRANSCOM 


7 


BROWSER 


13 


SARSS-O/RF/ 


X 




? 


? 


? 


7 


14 


INTEGRATED BROADCAST 
SERVICE OBS) 


X 




s 


NSA/NRO/AIA 

(JICPAC) 


UHF via 
landline 


CTT/MATT=>JTT 


15 


USE/LOCATION OF WMD 


X 




s 


JTF, JICPAC 


SIPRNET 


Browser Applications 


16 


INTEL IMAGERY 


X 




s 


JICPAC 


SIPRNET 


HTML, 5D, IPL client 


17 


DAILY INTELLIGENCE 
BULLETIN (DIB) 


X 




TSC 


JICPAC 


TSC Feed 


HTML, FrameReader, 
Adobe Acrobat 


18 


DAILY INTEL SUMMARY 
(DISUM) 


X 




s 


JICPAC 


SIPRNET 


Browser Applications 


19 


COUNTRY FACT SHEETS 


X 




s 


JICPAC 


SIPRNET 


HTML, FrameReader, 
Adobe Acrobat 


20 


DEFENSE INTELLIGENCE 
WARNING SYSTEM 


X 




s 


JICPAC 


SIPRNET 


Browser Applications 


21 


HULTEC DATABASE MESSAGE 


X 




s 


JICPAC 


SIPRNET 


Browser Applications 


22 


POL-MIL AND TACTICAL 
ADVISORIES 


X 




s 


JICPAC 


SIPRNET 


Browser Applications 


23 


TACMILINTSUM AND Sl- 
TACMILINTSUM 


X 




TSC 


JICPAC 


TSC Feed 


Browser Applications 


24 


EXPEDITIONARY SUPPORT 
PACKAGE 


X 




s 


JICPAC 


SIPRNET 


Browser Applications 


25 


FEASIBILITY ASSESSMENT 
SUPPORT 


X 




s 


JICPAC 


SIPRNET 


Browser Applications 


26 


MILITARY CAPABILITIES 
STUDY (MCS) 


X 




s 


JICPAC 


SIPRNET 


HTML, FrameReader, 
Adobe Acrobat 
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27 


JICPAC SPECIAL REPORT 


X 




s 


JICPAC 


SIPRNET 


HTML, FrameReader, 
Adobe Acrobat 


28 


TARGET SYSTEM ANALYSIS 


X 




s 


JICPAC 


SIPRNET 


HTML, FrameReader, 
Adobe Acrobat 


29 


LINES OF COMMUNICATIONS 
ROUTE STUDY 


X 




s 


JICPAC 


SIPRNET 


Browser Applications 


30 


OPERATIONAL TARGET 
GRAPHIC (OTG) 


X 




s 


JICPAC 


SIPRNET 


Browser Applications 


31 


BASIC TARGET GRAPHIC 
(BTG) 


X 




s 


JICPAC 


SIPRNET 


Browser Applications 


32 


QUICK RESPONSE GRAPHICS 
(QRG) 


X 




s 


JICPAC 


SIPRNET 


Browser Applications 


33 


TARGET INTELLIGENCE 
PACKAGE (TIP) 


X 




s 


JICPAC 


SIPRNET 


Browser Applications 


34 


IMAGERY INTERPRETATION 
REPORT 


X 




s 


JICPAC 


SIPRNET 


Browser Applications 


35 


MODERNIZED INTEGRATED 
DATABASE (MIDB) 


X 




s 


JICPAC 


SIPRNET 


Browser Applications 


36 


CONTINGENCY 
EXPEDinONARY/SOF 
PRODUCT (CESP) 


X 




s 


JICPAC 


SIPRNET 


Browser Applications 


37 


*NEO DATABASE *Not listed in 
message 


X 




s 


JICPAC 


SIPRNET 


Browser Applications 


38 


CURRENT INTELLIGENCE 
BRIEF 




X 


TSC 


JICPAC 


JWICS 


Monitor 


39 


J2 CHALLENGES BRIEF 




X 


TSC 


JICPAC 


JWICS 


Monitor 


40 


CNN 




X 


u 


CABLE TV 

(BROADCAST 

STATION) 


OCEANIC 

CABLE 


Television 


41 


AFRTS 




X 


u 


MARCH AFB, CA 

(BROADCAST 

STATION) 


INTELSAT 

I77W 


Television 


42 


UAV/HUD VIDEO DOWNLINK 




X 




PLATFORM BASE 
STATION 


BASE 

STATION 


Monitor 


43 


COMMAND INFORMATION 




X 


TSC 


JTF 


JTF 


Monitor 


44 


BDA 


X 


X 


s 


JICPAC 


Browser, 

JWICS 


HTML, Monitor 


45 


PSYCHOLOGICAL 
OPERATIONS PRODUCTS 


X 


X 




JPOTF 




Television 


46 


PREVENTIVE MEDICINE 
ORIENTATION AND TRAINING 


X 


X 


u 


SVCS, 

COMPONENTS 
(NAVY EPMU’S) 


NAVY 

EPMU’S 


Monitor 


47 


MEDICAL SIGNIFICANT 
TRAINING 


X 


X 


u 


SERVICES 
(ECHELON III 
UNITS, MEDICAL 
TEACHING 
FACILITIES) 


CONUS 


Monitor+H63 


48 


*NEO SUPPORT "Not listed in 
message 


X 


X 


7 


PACOM, NEO 
CENTERS 


? 




49 


EMERGENCY ACTION 
MESSAGES (EAM) 


X 




s 


COMUSKOREA 


SIPRNET 




50 


CINC FORCE DIRECTION 
MESSAGES (FDM) 


X 




s 


USFK 

(CINCUNC/CFC & 
USFK) 


SIPRNET 




51 


SITUATION REPORTS 
(SITREPS) 


X 




s 


USFK 

(CINCUNC/CFC & 
USFK) 


SIPRNET 




52 


FRIENDLY ORDER OF BATTLE 
(FOB) DATA 


X 




s 


USFK (CFC FIELD 
UNITS & 
SUPPORTING 
ORGS/ELEMENTS) 


SIPRNET 





54 




53 


ENEMY ORDER OF BATTLE 
(EOB) DATA 


X 




s 


USFK (CFC FIELD 
UNITS & 
SUPPORTING 
ORGS/ELEMENTS) 


SIPRNET 




54 


INTEGRATED TARGETING 
ORDER (ITO) 


X 




s 


USFK 

COMPONENTS 

(COMPONENT 

COMMANDS) 


SIPRNET 




55 


TARGET NOMINATION DATA 


X 




s 


USFK (CINCCFC, 

JICPAC, TARGET 

NOMINATION 

BOARDS, 

COMPONENT 

COMMANDS) 


SIPRNET 




56 


COLLECTION MANAGEMENT 
(RFIS) 


X 




s 


USFK (CP TANGO, 
OSAN AND CAMP 
HUMPHREYS, 
JICPAC) 


SIPRNET 




57 


HUMINT 


X 




s 


USFK (YONGSAN, 
CP TANGO, OSAN, 
HUMPHREYS) 


SIPRNET 




58 


GRAPHIC INTSUMS (Intel 
Summaries) 


X 






USFK (YONGSAN 
IN ARMISTICE, CP 
TANGO, CAMP 
HUMPHREYS, 
OSAN) 


SIPRNET 


ASAS/WARLORD 


59 


INTELLIGENCE ESTIMATE 
PRODUCTS 


X 




s 


USFK C2 (CFC C2) 


SIPRNET 




60 


KOREA TACTICS, TECHNIQUES 
AND PROCEDURES (KTTP) 


X 




s 


USFK C2 (CFC C2) 


SIPRNET 




61 


SIMULATIONS 


X 




s 


USFK, USCP 
(YONGSAN, OSAN, 
TAEGU, CP TANGO, 
SUWON, PACOM) 


SIPRNET 




62 


THEATER MISSILE DEFENSE 
INTEL PREPARATION OF THE 
BATTLEFIELD (TMD IPB) 


X 




s 


USFK (YONGSAN, 
OSAN, CP TANGO, 
HUMPHREYS) 


SIPRNET 




63 


SIGNALS INTELLIGENCE 
(SIGINT) 


X 




s 


USFK (YONGSAN, 
OSAN, CP TANGO, 
K-50, HUMPHREYS) 


SIPRNET 




64 


JSTARS 


X 




? 


JSTARS MGSM 
(WARTIME MGSM 
LOCATIONS) 




2D Imagery 


65 


VIDEO TELECONFERENCE 
(VTC) BROADCASTS 




X 


? 


USFK 

(CINCCFC/USFK 
AND VARIOUS 
PENINSULA 
COMMAND 
CENTERS) 


PAC VTC? 


VTC 


66 


DISTANCE LEARNING 


X 


X 


u 


USFK (ALL U.S. 
MILITARY POSTS 
AND CAMPS IN 
ARMISTICE. 
YONGSAN, OSAN, 
HUMPHREYS, 
TAEGU,JI2 
CHTNHAE, 
POHANG, AS A 
MIN.) 


? 


VTC, PASS-K 


67 


NONCOMBATANT 
EVACUATION OPERATION 
(NEO) SUPPORT 


X 


X 


s 


USCP, NEP CTRS 
(PACOM, NEO 
CENTERS) 


? 
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